하둡, 스파크, 파이썬등을 사용하고 있다. 많은 데이터들이 텍스트나 json으로 흘러다니고 흩뿌려 보냈다가 합치는 일을 반복한다. 데이터들은 디스크에서 메모리로 메모리에서 디스크로, 키를 사용하기 위해 돌아가며 피봇팅한다. 어디서 불합리한 바틀넥이 생길 것이라는 것을 개발자들이 어느정도는 예상할 수 있기에 나름의 튜닝을 한다. 스파크든 뭐든 계속해서 그 빈틈을 메꿔주자고 뭔가가 나오고 있다. MR에서 TEZ로, 디스크 연산에서 RDD로, 하이브대신 HBASE라든가, 디스크 대신 임팔라라든가. 메모리에 민폐일 것 같거나 재사용을 못할 것 같으면 .cache()를 쓰고, 병렬화 비용이 과다한 것 같아 병렬화 수를 줄이고 복딱복딱..중략.
네이티브, 날작업이 괴로우니 이제 프레임웤이 나온다. 프레임웤으로 일일이 제품을 만들자니 그것또한 품이 많이 들어 래핑하고 추상화한 라이브러리가 나오고, 시각화나 대시보드 솔루션이 나오고 그걸 가져다 바로 쓸 순 없으니 이제 대기업 SI에서 컨설팅을 하고 다양한 한국적 요구사항을 반영한 헬조선 패치를 한 제품이 나온다. 물론 여기선 개발만 괴롭다고 표현한 것 같은데, 유지보수 비용을 포함한 이야기다. 사실 프리미티브의 래핑작업이 우리네 개발자들의 많은 부분을 차지한다. 나는 이런 일은 낭비가 될 수 있으니 차라리 오픈소스를 찾아봅시다. 자사 전용 프레임웤(이라 쓰고 래핑이라고 읽는) 개발은 피해야됩니다 라고 말하는 편이다.
C언어로 데이터처리를 하기는 쉽지 않다. 문자열 쪼개고 붙이고 복사하고 파싱하는 작업도 지루한 노가다가 된다. 분산처리 역시 전용의 프레임워크를 사용하지 않는다면 날구현이라는 것은 매우 고통스러운 일이다. 시각화나 대시보드 같은 고차원의 추상화는 이미 이쪽의 업무는 아니다.
GPU 프로그래밍은 잘 모르지만 SIMD, AVX2라면 해봤다. 어쨌든 GPU의 문제점은 메모리 복사와 작업 개시전까지의 전처리 셋팅이다. 빠른 텀에 새 데이터를 밀어넣어 계산을 완료하고 즉시 응답을 주어야 하는 곳에서는 좋지 않다. 더 긴 텀에 많은 데이터를 밀어넣고 꽤 오랜시간 계산을 하고 비동기로 결과값을 받아와서 CPU나 GPU간 취합을 해야 하는 일이라면 괜찮다. 딥러닝에 있어서 GPU는 아직까지 좋은 선택이다.
NPU 프로세서가 등장하고 있다고 한다. 잘은 몰라도 병렬계산과 곱셈후 누산, 역수 계산, 16비트 단위 컴팩트 한 플로팅 처리, SIMD, openMP 지원이나 고도화된 쓰레딩 등을 잘 지원하는 칩일 것이다. 바야흐로 신시대의 DSP인 것이다. 이런 프로세서들은 GPU 메모리에 뭘 보내고 받고 작업 개시 셋팅 비용이 없으니 꽤 훌륭한 선택지가 될 듯 싶다.
아마도 5년내에는 메모리에 연산기가 달려서 나올 것이다. 예컨데 DMA 같은 식으로 일을 할 수 있다. "1000번지에서 10000번지까지 잡아다가 20000번지에 복사해." 라는 DMA 명령어는 명령어만 날리면 CPU가 다른 일 하며 놀 수가 있다. (사실은 2D 가속기에 가까운 기능이지만) 현대적인 AP를 비롯한 대부분의 임베디드 프로세서에는 이 기능이 CPU의 부가 기능으로 올인원 되어 있다. 인텔칩 같이 큰 칩들은 노스브릿기 같은데 있을 것 같다. 뭐 이런식으로 일을하면 메모리 버스야 바빠지겠지만 대개는 CPU 쪽이 더 바쁘므로 여유가 있을 수도 있고, NUMA 구조에서는 뺑이치는 버스만 뺑이치고 연산 쪽 CPU 버스는 다른 일을 할 수 있을 것 같다. (확인해본 것은 아니다.) 메모리에 연산기가 달려나오면 어떻게 될까. CPU는 다음과 같은 명령어를 메모리에 전달한다. "1000번지에서 10000번지까지 a[4] 단위도 얼라인되어 있고, a[1] * a[2] + a[3]을 계산하여 20000번지에 복사해놔" 라는 명령어만 전달한다. 칩 내부에서 연산하고 있으니 메모리 버스가 바빠질 일도 없다. 램 안쪽의 버스 라인에 SCV마냥 수천개의 컴팩트 ALU를 넣어둘지도 모른다. 초기 제품은 속도가 느려서 비동기적으로 결과 완료를 인터럽트로 알려줄 것이다. 중기 제품이 넘어서면 메모리 속도에 얼라인하여 즉답을 내줄 가능성이 있다. 후기 제품으로 들어서면 이 메모리의 가격이 매우 떨어질 것이다. 이에 대해서는 예전에 글을 쓴 적이 있다. 아마도, 이 제품의 명칭은 in place operating memory가 되지 않을까.
http://www.troot.co.kr/tech/20170816_in%20place%20%EB%A9%94%EB%AA%A8%EB%A6%AC%20%EC%97%B0%EC%82%B0.md
아..쓰려던 글은 이게 아니고, 비교적 큰 데이터를 조물락 거리고 있노라면 대형 분산처리는 전처리에서 시행하고, 꽤 쓸만한 물리 머신의 소규모 분산처리로 할 수 있는일이 꽤 있다는 것이다. 지금은 낭비가 너무나도 많다. 지금 여건에서 낭비제거는 일종의 흑마술 취급을 받기 좋다. 사람값이 싸기 때문에, 비록 눈꼽만큼 어려운 일이지만 그렇게 일을 하는 방식이 더 낭비라고 생각하기 때문이다. 간단한 머신러닝 알고리즘을 돌릴때마다, 아 이걸 그냥 메모리에서 하면 될텐데 하는 생각을 종종한다. 아니 이걸 어떻게 메모리에 다 올려? 하는 일들이 사실 메모리에 많이 올라간다. 인덱스를 붙여서 숫자로 만들고, 컴팩트한 프리미티브 자료구조를 쓰고, 가능한 배열화 하고, 아웃라이어를 전처리에서 제거하고, 뚝딱뚝딱하다보면 어라? 요즘 장비면 그냥 올라가겠는데 이거? 게다가 난 GPU도 모르는데 SIMD만 가지고도 속도 뽑겠는데? 하는 일들이 있다는 것이다.
sparse한 데이터는 검색이 수반되어 배열화를 못할 것 같지만 사실 방법이야 몇 있다. 예를 들어 인덱스와 값을 페어로 배열화 하여 소팅하여 저장한 다음, 인덱스의 바이너리 써치를 수행할 수 있다. 그럼 소팅 비용이 들지 않느냐고 할 수 있는데, 트레이드 오프를 계산해서 판단할 일이다. 예전 경험을 비추어보면, 트리로 만들었다가 배열로 직렬화 했다가 왔다갔다 하는 일이 필요한 것 같다. 성능을 위해서다. 빠른 탈출이 있는 퀵소트만으로도 꽤 괜찮은 성능을 얻은 경험이 있다. (이런 소팅에 이름이 있었는데 까먹었다.) numpy 같은 것을 뜯어보진 않았지만 뜯어보면 아마 사람들이 생각하는 방식이 다들 비슷하지 않을까 싶다.
쓰려던 글이 이게 아니었는데.